home *** CD-ROM | disk | FTP | other *** search
/ 17 Bit Software 3: The Continuation / 17-Bit_The_Continuation_Disc.iso / arug / arug 5 / misc.notes < prev    next >
Text File  |  1994-01-27  |  4KB  |  86 lines
  1.    These are some short notes on JR-Comm and may help eliminate a few
  2. problems you may run into...
  3.  
  4.  
  5. Amigas with less than 1Meg free memory
  6. --------------------------------------   
  7.    Alot of people have had some problems with editing in the phonebook due
  8. to limited memory.  There's no doubt about JR-Comm sucking up major amounts
  9. of memory when three requesters are open on a 16 color screen.
  10.  
  11.    In fact, the very worst case condition is when using 16 color interlace
  12. screen and you open the transfer parameters requester from the directory
  13. entry edit requester.  In this case about 293k of chip ram is required to
  14. accomplish this.
  15.  
  16.    Now, if you were to change the screen to a two color non-interlace screen
  17. and do the same operation you'll see that the chip requirement drops to just
  18. 62k of chip ram!  You will still need the 210k of fast ram that JR-Comm uses
  19. for itself, but you can save almost 230k of chip ram by using the two color
  20. non-interlace screen over the 16 color interlace screen. A 16 color non-
  21. interlace screen uses about 75k less chip ram than the interlace version in
  22. the same situation.  BTW, with the three requesters closed a two screen uses
  23. about 240k of total ram, about 20k of it being chip.
  24.  
  25.  
  26. Display flickers during scrolling
  27. ---------------------------------
  28.    Certain colors in a 16 color display cause a noticable flicker to occur
  29. as the text is scrolled up or down the screen.  Unfortunately, this is an
  30. unavoidable side-effect due to four bitplanes of screen data being scrolled,
  31. one-at-a-time, by the blitter.  If this is very disturbing to you then use
  32. an 8 color display where there is little, if any, visible flicker.
  33.  
  34.  
  35. High baud rates and 16 color displays
  36. -------------------------------------
  37.    Another thing people have been running into is trying to drive their
  38. Amiga too hard by using a high speed modem like the HST at 19.2k with a
  39. 16 color screen.  While you're not going to break anything physically, you
  40. are going to lose data, period.
  41.  
  42.    What happens is that a 16 color display is robbing the cpu of alot of
  43. processing time while the display is being painted on your monitor.  Every
  44. now and then data is going to get lost because the cpu doesn't get the
  45. characters out of the serial port fast enough at high baud rates.  At 2400
  46. baud you won't have this problem since the data is coming in slow enough
  47. for the cpu to get at it.
  48.  
  49.    You may notice that during a file transfer the bright colors of a 16
  50. color display will dim.  What is happening is that one of the bitplanes
  51. is being turned off during the download to give the cpu a bit more
  52. processing time to give the best downloads times possible for 2400 baud.
  53.  
  54.    At faster baud rates this isn't enough, you're going to need to drop
  55. down to a Workbench screen or a 2 or 4 color custom screen to get better
  56. transfer rates.
  57.  
  58.  
  59. Interlace and/or morerows
  60. -------------------------
  61.    These modes also require more from the Amiga than a normal display.
  62. While interlace has no effect on DMA when the display is static, it does
  63. extract a DMA penalty when scrolling is performed because twice as many
  64. bits have to be shuffled.
  65.  
  66.    Morerows takes up more DMA since you're displaying more data, it's
  67. fairly simple.  Please keep these in mind before deciding that JR-Comm
  68. is "losing" data or otherwise performing poorly.
  69.  
  70.  
  71. Chars/sec during transfers
  72. --------------------------
  73.    JR-Comm is *very* conservative about its character/second calculations.
  74. It only uses the amount of actual data for the file received, no overhead
  75. data is included to "pad" the calculation and give better throughput then
  76. is really being acheived.  For XMODEM type protocols the clock is started
  77. as soon as the transfer is started. CIS B+, YMODEM and ZMODEM start the
  78. transfer clock after the file info data block has been received and
  79. processed.
  80.  
  81.    The rate will even out as the length of the file grows, short files tend
  82. to give less accurate, even overly ambitious results.  Files over 50-75k in
  83. size give a much more realistic figure.  Larger files are needed for high
  84. speed modems to give more accurate results.
  85.  
  86.